O PI c 

OmCS Dl LA MOHliri 

NTILUCTU1LLI DU CaKaDA 




CIPO 

Canadian Intiiaictual 
Phohutt Orrici 



(i2)(i9)(CA) Demande-Application 



(72) BREALEY, Chris L., CA 
(72) JOHNSTON, JefTG., CA 
(72) KLICNIK, Vladimir, CA 
(72) LAUZON, David M., CA 
(72)LOI,Lok T..CA 
(72) SEELEMANN, Alek D. II, CA 

(71) IBM CANADA LIMITa-D - IBM CANADA LDvUTEE, CA 
(51) Ii.t.CI. 6 G06F 9/45 

(54) MEMOIPE HTERARCH1QUE DE METADONNEES DESTINE E A 
UN ENVIRONNEMENT DE DEVELOPPEMEN T INTEGRE 

(54) HIERARCHICAL METADATA STORE FOR AN INTEGRATED 
DEVELOPMENT ENVIRONMENT 



(2D(Ai) 2,201,278 

(22) 1997/03/27 
(43) 1998/09/27 



OCNEXAUZEOMT 

• METHODS 

• SUBPART! 

• MHBtfTANCE 



3 


4 


5 




8 


7 




F 










5 


n 

l 


T 
V 




COMPOMEMrfAfTTt 


u 


T 


M 


P 


E 




ft 


1 


c 


N 




N 


U 

c 


T 
1 


D 


E C 


9 


1 

O 


T 


V 


E 


S 




N 




c 


F 




PAKTTnOHAjLE 


% 




• 


• 


1 


CONTAINER 





SPCCtAUZO 



(57) Depot de mdtadonnees pour un cnvironnement dc 
developpement integre*. Lc depot est divis* en couches 
dc facon a definir des oiveaux de com port cment commun 
utiles a differents types d 'outils de developpement 
d 'applications. Les outils d'uulisation la plus generalc 
om acces aux rnetadonnees au niveau de types a structure 
simple; les outils plus specialises om acces a des 
composantes qui contiennen: les proprietes d*un langage 
cible; les outils dc haute specialisation ont acces a des 
me*tadonnees cornposees a parties segmentablcs qui 
peuvent servir a const i^ier des applications reparties. 



(57) A metadata repository for use in an integrated 
development environment h provided. The metadata 
repository is layered to define levels of common 
behaviour useful to different types of application 
development tools The mo<rt general use tools have 
access to metadata at the level of simple constructed 
types; more specialised tools have access to component:, 
that contain properties of a target language; highly 
specialised tools have access to composed partitionable 
part metadata that can be used for constructing 
distributed applications. 
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HIERARCHICAL METADATA STORE FOR AN INTEGRATED DEVELOPMENT 

ENVIRONMENT 

Abstract 

A metadata repository for use in an integrated development environment is provided The metadata 
repository is layered to define levels of common behaviour useful to different types of application 
development tools. The most general use tools have access to metadata at % level of simple 
constructed types; more specialised tools have access to components that contain properties of a 
target language; highly specialised tools have access to composed panitionable part metadata that 
be used for constructing distributed applications. 
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HIERARCHICAL METADATA STORE FOR AN INTEGRATED DEVELOPMENT 

ENVIRONMENT 

Field of the Invention 

The present invention relates in general to the data processing field, and more spe:i5ca!Iy to the 
provision of an integrated tool development environment. 

Background of the Inventinp 

Traditional tool development follows the simple steps of creating the text-based source code, and 
then compiling and executing the code on a specific platform The increasing complexity of function 
and integration of tools over multiple platforms means that tool development cannot generally be 
performed by small groups of human developers Often the only way to produce a fully functioning 
application is to make use of specially-designed application development tools in order to build other 
tools. Today's applications are built using a mix of low level tools such as source editors and 
debuggers, along with high level builders of user interface, data access, distribution support, and code 
generators. The applications built in such environments are targeted to run in a multiplicity of 
execution environments, on various hardware platforms, supporting many distribution mechanisms 
and data access mechanisms. Developing such applications in the current "state of the art" requires 
the use of multiple different tools for multiple different vendors, each solving a piece of the over all 
puzzle. 

The idea! is to provide an integrated development environment (IDE) in which information provided 
by each tool during program development can be shared with other tools, particularly those being 
used in the same development effort, to avoid duplication and inconsistent interface and function 
operations Currently available development tools address only a small subset of this requirement 
They typically focus on a source-level, single targeted application, and use a simple file system 
folder/directory model for their information 
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Where the application development tc* are tightly integrated, they can often use cross reference 
tables to share information about the program und.r development. However in an incremental 
development environment, the tables can be out of synch with the source code, and frequently contain 
less information than implied by the source code. 

5 

Also, any tool not closely integrated (and this is often the case with tools from different 
manufacturers) wiU have to parse the source or the tables, provided the programming language is not 
a bamer This parsing exposes the tool either to parsing differences or internal table definitions 

10 Summary nf t^ e [nyfntinn 

One of the key problems that needs to be addressed dunng construction of an IDE for a complex 
.ppl.ca.ion is the ability of the various IDE tools and components to share information in a 
meanmgfu. way. An "information store" is required to facilitate this sharing Such a store must 
support usage and access characteristics of a multi tool/multi user environment and provide a flexible 

1 5 basis for capturing required semantic information 

The store must also define an overall ^formation structure about applications under development 
and organs it in a way that offers the degrees of freedom required by today's applications These 
degrees of freedom include choices of targets, languages, component models, distribution etc The 
IDE further needs to define a mode, for sharing common application semantics among the 
cooperatmg tool, but at the same time allow individual tools to extend the shared information with 
pnvate too. data. The model also need to "manage" programming "element" naming issues (naming 
scopes) across the various domains implied by the degrees of freedom. 

Therefore, an object of the present invention i, to provide a mechanism for organizing metadata in 
support of the development of comp.ex enterprise app.ications by defining a layered data model for 
handlmg app.ication development metadata, addressing the various application degrees of freedom 
within a single metadata store. 
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In 3ccordance with these objects, the present invention provides a metadata container for common 
access tool data in an object oriented programming environment The metadata container has a 
hierarchical structure that consists of simple constructed types containing subparts and encapsulated 
behaviour, components containing properties of a target language, and composed parts permitting 
5 partitioning for distribution. 

The present invention also provides a metadata store for common access tool data in a object oriented 
programming environment consisting of a single base class defining common behaviour for elements 
in the tool data, and separate abstract class hierarchies, inheriting from the single base class, to define 
1 0 name scope and containment for tool data. 

Brief Description of the Drawing? 

Figure 1 is a schematic drawing illustrating categories of metadata layered "parts" according to the 
preferred embodiment of the invention, and 

15 

Figure 2 is a tree diagram illustrating the model layer hierarchy according to the preferred 
embodiment of the invention, and 

Figure 3 is a class diagram, expressed in C++, of an IDE element base class, according to the 
20 preferred embodiment of the invention 

Detailed D escrintion of t he Pr eferred Ernhndimgnj 

The preferred embodiment has been implemented as an open data model that provides source code 
or the common intermediate form accessible and extensible by all development tools that wish to 
25 work with a program The data model is language independent which allows cross system source 
sharing This model could be use to drive a code generator. 

In the preferred embodiment, the data model provides a metadata store in support of a tool 
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integration framework which is folly described in our concurrent^ filed application titled "An Object 
Oriented Framework Mechanism Providing Common Object Relationship and Context Management 
For Multiple Tools" (IBM Docket No CA997-002) 

In order to handle the requirements of the range of applications, from basic source programming to 
component based visually constructed applications, the data model of the present invention provides 
a shared metadata store in which the development information is layered Each layer defines the 
common behaviour required at that level. Tools using the model start with a behaviour at a given 
layer and extend it as appropriate for the particular tool. 



The data model captures information about various "elements" required during the development of 
an application. This includes information abou- the logical pieces of an overall application, such as 
folders, ties and application parts. At its highest level, the data model generally defines the common 
behaviour required to be recognized as an element within the integrated development environment 
15 This includes the ability for rendering the element, exposing its content (if appropriate), as well a 
triggering any of its actions. 

This is roughly equivalent to other currently available application development information stores that 
map to a file system (source files and directories/folders) However the data model of the invention 
20 is further extended into key areas: 

I. recognition of namespaces as distinct from folder coniainment; and 
2 refinement of the application "part" concept into distinct part layers 



Rather than leaving it to the developer to recognize project folder containment and application part 
naming at the source or force the naming relationships to be the same as the folder containment, the 
data model of the present invention defines name scope as a "parallel" set of relationships to that of 
cornainment. This allows, for example, a part containing a C++ class A B :C to be properly defined 
as a series of nested naming scopes, while at the same time allowing the same part to be used 
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(through containment or linking) within several project folders. 

The data model of the invention supports application definition and assembly from parts According 
to the invention, a part is a self contained piece of an overall application that is distinct from the 
source files that contain the source code for the pan Depending on the programming environment, 
a part rmy in fact reference several files (hr example in 0+, the hpp and cpp files) but a part is not 
a file container Within the data model of the invention, a part is a separately editable piece of 
application definition (metadata) distinct from any source files that may be associated with the part 
or generated from the part definition As will be discussed in more detail below, within the data 
model of the invention, all parts are named and name scoped A part (based on its implementation) 
may itself be a name scope for other parts, as in, for example, C++ nested classes 

The layering approach to a metadata store is schematically illustrated in Figure 1 The semantics of 
a part 1 are layered in a spectrum in the data model from parais used by general use tools to parts 
used by increasingly specialised tools 

At the general end of the spectrum, Generalised Parts 2 are base parts corresponding to the semantics 
of a constructed type within the target language The list of generalised parts include subparts and 
encapsulated behaviour such as methods and inheritance Typically, these correspond to a class 
definition for object oriented languages such as C++ and Java™, or to some form of a structure, such 
as in COBOL 

A degenerate case of the generalised parts are various types supported by the data model These 
types arc further specialisations of generalised parts that capture or encapsulate the following 
concepts: fundamental types (eg int, ch?r) are represented by Primitive Types 4, records are 
represented by Structs 3, overlaid memory structures are represented by Unions 7; named cardinal 
values are represented by Enumerations (Enums) 6, and aliased parts are represented by Type 
Definitions (Type Def) 5. 
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Component parts 8 are base name parts with the additional suppo.t of a component model A 
component part, regardless of its ultimate source language implementation, defines its external 
behaviour as a set of attributes which are called "properties", events raised by the part and actions 
which are externally triggerable behaviour. The data model captures this information as a component 
part and allows the generation of the appropriate target component model (eg Java Beans. IBM® 
VBE model, etc ) Within an IDE, this typically represents the level of support used by higher order 
•builder" tools. Component parts are referred to within the data model as "builder consumable" parts, 
in relation to Figure 2 

Parthionable containers 9 are component parts that expose part of their internal behaviour to a level 
that allows repartitions of the part for distribution. Through the data model, these parts expose 
interactions among their aggregated subparts, as well as interactions across parts This level of 
mformation is used to capture the application distribution structure regardless of the targe, 
distribution mechanism. 

Depending on its specific requirements, a tool selects the appropriate level of parts support to store 
rts tool par, metadata within the data model. Shared behaviour is inherited from the data model and 
the tool adds it own extensions as appropriate Typically, these extensions are opaque tool-specific 
propert.es For example, this structure allow, a data access par, which is a component part 
eontammg tnformation about access to a data base, to be consumed by a user-interface (UI) builder 
producing a UI pan. The UI builder is a composed part containing the data access part and UI 
controls Th» can subsequently be partitioned into a client par, (UI and server call) and server par, 
(server log,c) and access to data base This is all done by editing the da,, model information The 
same data model information can be used to generate a Java bean with RMI call to server and JDBC 
access to da,, base, or . C~ client with DCE access to a serv er with a local data base 

The preferred embodiment i, in^nented in .n object oriented programing hierarchy which 
ftchutes the sharing of p.rts through inherence Figure 2 ^ustrates ,n approach to data mode. 
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layers according to the preferred embodiment providing a class definition a* each layer and illustrating 
how the class of metadata, at that level in the hierarchy, can be used by tools. 

The most abstract base class, the IDE Element 20. is provided for the implementation of an *DE tree 
view Using mostly pure virtuaJ method', it permits the tree view to display the contents of the 
model, launch actions against its elements (nodes), and attempts structural changes against the 
hierarchy without regard to the content details Success of these operations (especially structural 
changes) depends on the supported semantics of the individual tree element derivations 

The common behaviour of rendering of tree nodes is denned so that each element within the tree view 
will show its name, icon, indication whether element is owned or link.d. ard an indication whether 
the element can be further expanded 

The basis for expanding branches of the tree view is the ab.lity to list the contents of any one IDE 
element as its contained element. Thus, the IDE Element base class 20 provides a common behaviour 
to expose content This is illustrated, in the preferred embodiment, in the sample C++ header file for 
an IDE Element base class set out in Figure 3. Each derived IDE element determines what 
constitutes its content Unlike most other relationships supported within the model, the "contains" 
relationships have a requirement for supporting direct access to its element by name, as well as 
providing cursor based access that maintains ordering. This is required because the tree view is 
expected to allow the nodes within the tree to be reordered using drag and drop operations or the 
selection of reordering actions The relative element order is maintained within the model A specific 
example of this is a visual builder pallet containing pallet categories, each of which contains parts 
available to the builder Frequently used items would be expected to be placed at the top of the list 
to reduce the need for scrolling 

The model also provides a set of methods at this level of abstraction that allow modifications to the 
tree structure without regard to element details The success of these operations is determined by 
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the derived implementations There are two mechanisms for constructing container relationships: 

1. Ownership relationships indicating aggregation of the sub elements within the subject parts. 
Owned elements are destructed if orphaned by a parent, and 

2. Reference relationships indicating soft links or shadow links to a sub element owned or 
aggregated elsewhere within the tree 



In all cases, a removal action on one element propagates the removal action across ownership 
relationship but not reference relationships That is owned elements are destructed but in the case 
of linked elements only the link is removed. It should be noted that the data model does not enforce 
a single owning parent rule, although a great majority of owning relationships are expected to be of 
this type In an owning relationship, the child is destructed when any parent is destructed or when 
the child is explicitly orphaned by any owning parent 

Since derived implementation may reject attempt to change the contents of ths tree nodes, methods 
are provided to check if the desired operation is allowed Even if the operation is allowed it may still 
fefl for other reasons The decision to accept or reject a content action is up to the object that is the 
recipient of the content, that is the parent object would be asked for permission not the child object 

In the preferred embodiment, the IDE Element base class 20 provides additional common behaviour, 
including: 

1 action support: the model provides a mechanism for triggering edit actions against the 
model objects. The term "edir simply means any tool specific action Each tool is expected to 
provide an implementation of the edit methods in their concrete class derivations 

2 code generation support: each element can cause source output to be generated for the 
model metadata A default implementation of generate () is to simply return If output must be 
produced, the dsrived implementation need to over ride the generate () method This generate () is 
a context senritive method 

3. "dirty" part support an IDE element can be marked by a tool as being "dirty" This 
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indicates that the source code for the element must be regenerated because it or its dependencies have 
changed. The model provides a method to manage this indication shown in Figure 3. 

4. associated file operation the model makes the distinction between contained and 
associated files A contained file is simply an DDE element ihat is structurally related to its container 
5 An example is the source files contained within a project group folder Contained files are 
manipulated using the content and structural operations discussed earlier in this section. An associate 
file is a file reference that is required to further define the IDE element it is associated with An 
example of an associated file or header files required in order to use a part, or source files generated 
from a group or a part. When most cases these are not actually contained within the element with 
10 which they are associated 

At the next level of abstraction are the Containment Scope 22 and Jame Scope 24 base classes As 
mentioned above, containment and part naming are parallel, and therefore, independent relationships 

15 On the containment scoping side, the base class 22 represents a generalized groining construct In 
hs default form, it aJlows an arbitrary collection of groups, parts and fees that can be owned or linked 
Also by default, its content can be "edited" through the tree view or a tr >I action This is a genera! 
"folder" 40 construct within the IDE 

20 The base Name Scope class 24 defines support for nested name scopes within the preferred 
embodiment model Its primary intent is scoping of name pans The Name Scope Folder 26 and 
Named classes are used to construct the hierarchy reflecting the definitional scopes of the pans This 
hierarchy is parallel to that of containment, to allow name scoping to be independent of part 
attainment 

IS 

The Namescope Folder class 26 is in all aspects identical to the Containment Scope class 22, except 
it also defines a name scope Namescope Folder 26 is to allow name scope other than name groups 
and the derivations and pans in their derivations This is a general names based construct within the 
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Scoped names are constructed by assembling a nested set of scopes using the group and pan 
construct, Model, the singleton basis of the structure, plays the role of the global naming scope 
Constructors are provided on group and part derivations that allow specification of ;he parent name 
scope for the hem being constructed. If a name scope for these objects are not specified the 
constructed objects are defined at a global scope, that is created below model in the name scoping 
hierarchy * 

In general, tree nodes also act as local name scopes for the immediate children they contain By 
default, duldren of an element must have unique names Since part names are globally unique (under 
the name scoping mechanism), the default model imputation will al | 0 w a part ,o be created 
•ndependen, of any non-part construct that may exist with the same name bu, wil. not al.ow a part 
to be stored in an element container if the container already has a non-p,t child with the same name 

Continuing in the Name Scope hierarchy, the Named Part class 28 represents a generalized pan 
construct 44. By default, its content is editable only via an explicit too. action The pan class is not 
a folder, although it may be defined as an aggregate of sub-pans 

The Named Pan class models are based constructed type, and permits the data mode. ,o capture 
."formation about mode, defined anributes and properties, inheritance, data member and sub-pan 
aasregat-on. and externally triggerable behaviour or methods All pans can ac, as name scopes for 
other parts 
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The Builder-Consumable Part class 32 implements semantics of a component part These builder 
parts are consumable by the visual composition editor (graphical composer) They are defined in 
terms of attributes, events and actions At generation time. Builder-Consumable parts feat.re maps 
to the appropriate target component model 46. 

Builder-Composed Part class 34 is a partition class that defines the semantics of a partitionable 
composed part, as distinct from a distributable par, I, should be pointed out that a part is 
Astributable if builder tools are allowed to use a proxy to access a remote instance of the part In the 
data model, this is indicated by a part property. A part is partitionable if distribution support can 
effecfvely rearrange the par. content across two or more parts Concrete parts derived from this 
class map to composed parts 48 and are partitionable by distribution support. 

Local associations among a part's sub-parts are captured within the pan definition. They represent 
sub-par, mteractions Methods are provided to handle the repartitioning of a part which occurs by 
redeploytng a sub-par, from one part to another If this redeployment is successful, a distributed 
assoaauon between the parts is created These represent distributed cross part interactions between 
sub parts of different parts. 

A final base class is the File Reference Cass 36 which represents a generalized file reference construe 
It is a symbolic pointer to a file item 50 in the file system 

Embodiments of and modifications to the described invention that would be obvious to those skilled 
in the an are intended to be covered by the appended claims 
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The embodiments of the invention in which an exclusive property or pri\ilege is claimed are defined 
as follows: 



1. A metadata container for common access tool data in an object oriented programming 
environment, having a hierarchical structure, comprising: 

simple constructed types that contain subparts and encapsulated behaviour, 

components that contain properties of a target language, and 

composed parts that permit partitioning for distribution 

2 A metadata store for common access tool data in an object oriented programming 
environment, comprising: 

a single base class defining common behaviour for elements in the tool data, and 
separate abstract class hierarchies, inheriting from the single base class, to define name scopes 
and containment for the tool data 

3. A metadata store, according to claim 2, wherein the abstract class hierarchy to define name 
scopes comprises: 

a part class representing a generalized pan construct adapted to contain subparts and 
encapsulated behaviour. 

4 A metadata store, according to claim 2 v j, wherein the abstract class hierarchy to define 
name scopes comprises 

a component class adapted to implement properties of a target language 

5 A metadata store, according to claim 2 or 3, wherein the abstract class hierarchy to define 
name scopes comprises 

a partition class adapted to contain definitions of part partition semantics 
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6 A metadata store, according to claim 2, wherein the abstract class hierarchy to define name 
scopes stratifies the tool data into a layered structure, comprising: 

simple constructed types that contain subparts and encapsulated behaviour, 

components that contain properties of a target language; and 

composed parts that permit partitioning for distribution 
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